home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 7638 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.1 KB
  1. Path: oldsuna.gmr.com!news
  2. From: David Brown <dbrown@cgs.c4.gmeds.com>
  3. Newsgroups: comp.lang.pl1,comp.lang.c
  4. Subject: Re: PL/I and C
  5. Date: Tue, 27 Feb 1996 14:33:43 -0500
  6. Organization: Electronic Data Systems
  7. Message-ID: <31335C97.41C6@cgs.c4.gmeds.com>
  8. References: <4gh5ru$eng@goanna.cs.rmit.EDU.AU> <4gn5d8$t5f@newsbf02.news.aol.com> <4gril3$sn9@goanna.cs.rmit.EDU.AU> <31320777.2810@corp.dialog.com> <4gt5sm$jra@fountain.mindlink.net>
  9. NNTP-Posting-Host: reality.cs.gmr.com
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 2.0 (X11; I; IRIX 5.3 IP19)
  14.  
  15. I just thought I would throw my two cents into the fray :-)
  16.  
  17. I have programmed in PL/I and C.  When I first started using C I thought
  18. it was not as good a language as PL/I.  This was partly due to my level
  19. of knowledge of the language.  The more I use it the more I like it. 
  20.  
  21. The programming style used in C is very different from PL/I because of
  22. pointers and arrays.  Once I modified my programming style to be more C
  23. I appreciated the language more.  For example, I like typed pointers,
  24. typedef's, pointer arithmetic.  
  25.  
  26. However, there are some things which I miss in PL/I.  Self defining
  27. varying length structures, better character string manipulation area
  28. variables, and better preprocessor.  I sure if I thought about it there
  29. would be others.
  30.  
  31. Both languages have features I hate.  C's inability to skip levels of
  32. data structures.   C's complex declarations.  PL/I's complex I/O.
  33. PL/I's lack of bit shift functions.  PL/I's complex automatic conversion
  34. rules.
  35.  
  36. When I first started using C it was very easy to hurt yourself.  Since
  37. then ANSI C with prototypes and stricter casting rules has made it
  38. harder, but I still think it is easier to produce a bug in C then in
  39. PL/I.   However, the reality is there are more C debuggers and tools
  40. being produced then PL/I.  As time goes on C will become more productive
  41. simply because of the quality of the tools.  
  42.  
  43. Because of the development environment issue I usually push C over PL/I.
  44. That doesn't mean it is a bad language.
  45.  
  46. David
  47.